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DETAILED ACTION 

1 . This action is responsive to the Applicant's response filed 12/20/2006. 

As indicated in Applicant's response, no claims have been amended. Claims 96- are 
pending in the office action. 

Amendment and request under 37 § 1.48(b): Objections 

2. The request for the deletion of an inventor in this non-provisional application under 37 
CFR 1.48(b) is deficient because: there is no change in the claims as of the present submission as 
a direct result of the Office Action in effect and filed as of 8/16/06. 

j 

A) That is, according to CFR § 1.48(b), any amendment wherein a deletion of subject 
matter or cancellation of claims requires proper signed action from the party set forth under CFR 
§ 1.33 (b) (Applicant's representative or assignee) to the effect of establishing the following: 

(i) effectuating the amendment with removal of subject matter as a result from a 
prosecution; 

(ii) acknowledging that the remaining subject matter in the amendment requires removal 
of names of inventors (that have become no longer pertinent to claimed invention) as a direct 
consequence of said cancellation or removal of claims; 

(iii) filing the amendment addressing the above claims change (or deletion) along with a 
request under CFR 1.48(b) with appropriate fees under 1.1 7(i) in order to request removal of the 
inventors that are identified from (ii) 

The presently submitted Request under § 1.48(b) does not fulfill the above requirements, 
as follows: 
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as per (i) the prosecution of record and filed 8/16/06 is not perceived as having triggered 
any removal of claims , i.e. the claims presently resubmitted as 96-1 13 are identical to those 
previously submitted in 1 1/23/05; 

as for (ii), there is no statement from the Applicant or representative that would 
substantially establish how the amendment (with deletion thus effected) corresponds solely to the 
a subset of inventors, as opposed to belonging to whole Inventive Entity set forth and filed in the 
original Oath of Declaration; 

as per (iii), the filing of an amendment with change of claimed subject matter is NOT 
present as a result of the outstanding Office Action; i.e. the submitted claims have to include 
removal/deletion; that this removal has to be directly subsequent to the current state of 
prosecution, and submitted with a proper § 1.48(b) including a statement required in (ii). 

In short, if a prosecution stage triggers any deletion of claimed subject matter, the 
ensuing amendment to the effect of submitting the deletion/removal has to be accompanied 
timely with a proper § 1.48(a) explaining why the remaining claimed subject matter (as 
resubmitted) is pertinent only to a subset of the original Inventive Entity, thus requesting 
removal of part of the inventorship that is commensurate with that change. 

B) Applicants' repeated submissions in response to the Examiner's Office Actions 
pertinent to the remaining claims 93-1 13 have been deemed silent to any need to remove 
inventorship, and otherwise receptive to said prosecution of record, i.e. implicit admission of the 
scope of the inventorship relevant to the claimed subject matter being addressed (claims 96-1 13) 
by the various stages of prosecution. 
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That is, the removal of claims 1-95 effectuated as per 11/23/05 as mentioned by 
Applicants had been submitted (as claims 96-1 13) without a timely and proper § 1.48(b) as a 
consequence of the prosecution of 5/19/05. The subsequent Office Action filed 2/24/06 did not 
generate any changes in the claims, which remained unchanged (claims 96-1 13), and if they did 
change, a proper § 1 .48(b) would have to be filed subsequent to that Office Action, which did not 
appear to be the case. Claims 96-1 13 resubmitted as of 7/17/06 had again been without a 
statement from the Applicant declaring that the remaining subject matter require that some 
inventors' names be removed as otherwise required for a proper § 1 .48(b). It is noted that only 
after the Office Action as per 8/16/06 has been in effect did the Applicants decide to remove the 
inventors' name to readjust to the subject matter claims, an step that would have to be properly 
and timely taken much earlier (e.g. 1 1/23/05). 

It is unclear as to how the Office actions filed as rejections of 2/24/06 and then again 
8/16/06 addressing the remaining claims 93-1 13 did not trigger any declaration from the 
Applicants to the effect that the remaining subject matter only pertains to a subset of the original 
Inventive entity. 

Lacking evidence to support why the filing of a 1.48(b) is not timely filed to properly 
address a change in scope of a claimed subject matter and inventorship, it is deemed that the 
grounds for a.proper request as a § 1.48(b) thus submitted above are insufficient. Therefore, the 
request for removal of inventors name is not considered; thereby the subject matter presented by 
claims 96-1 13 as now resubmitted (without any deletion) will be treated in the context that they 
are pertinent with the original set of inventors as set forth in the original Application, i.e. in the 
OATH of DECLARATION. 
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Claim Rejections - 35 USC § 101 

3. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

4. Claims 96-1 13 are rejected under 35 U.S.C. 101 because the claimed invention is directed 
to non-statutory subject matter. 

The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, 
concrete, and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a 
• patent. As a consequence, an invention, which is eligible for patenting under 35 U.S.C. § 101, is in the 
"useful arts" when it is a machine, manufacture, process or composition of matter, which produces a 
concrete, tangible, and useful result. The test for practical application is thus to determine whether the 
claimed invention produces a "useful, concrete and tangible result". 

Specifically, claims 96 recites a method for designing software system, comprising 
defining design parameters (DP) parameters, decomposing set of functional requirements (FR) 
and said parameters to create hierarchy thereof, defining a matrix for mapping parameter and 
requirements of such hierarchy, and use the matrix to further define object oriented structure 
wherein a FR represents an OO object and a DP represents a input to said object. The claim as a 
whole amounts to defining a software structure with descriptive elements representing parts of 
the software structure. The final result thus conveyed does not reasonably teach that a tangible 
real-world result has been generated at the end of the method steps leading to defining of a 
software structure. That is, such structure even defined via a software design method remains 
but an abstract entity internal to a definition process, hence not externalized into a tangible entity 
because a mere definition process appears to be just a internal or abstract function effectuated by 
a programmatic process. Lacking the characteristic of being tangible, the abstract entity is 
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therefore not useful because it remains non-practical, not perceivable in order to be of any use; 
and without being of any use, it cannot be a concrete application result. The claim for failing to 
convey the yielding of a concrete, useful and tangible result, is rejected for leading to a non- 
statutory subject matter. 

Claim 105, similar to claim 96, amounts to defining a structure without any further 
teaching on any practical use of the structure in order to yield a real world useful result. And in 
light of the rationale as set forth above, claims 97-104, and 105-1 13 are rejected for the 
deficiency of not fulfilling the Practical Application requirement. 

Claim Rejections - 35 USC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 96-1 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Nam P. 
Suh, "Axiomatic Design Theory for Systems", Research in Engineering Design, Vol. 10: pp. 
189-209, MIT 5 1998 (hereinafter Suh_l), further in view of Sung-Hee Do and Nam P. Suh, 
"Systematic OO Programming with Axiomatic Design", IEEE Computer, Vol. 32, No. 10, Oct 
1999, Integrated Engineering, pp. 121-124 (hereinafter Suh_2). 

As per claim 96, Suh_l discloses a method of designing a software system, comprising: 
defining a set of functional requirements that describe what the software system is to 
achieve (e.g. FRs-Fig. 1- pg. 195; Fig. Al, pg. 204; ch. 4.1, pg. 191); 
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defining a set of design parameters, where each design parameter in the set satisfies at 
least one of the functional requirements ( DPs - Fig. 1, pg. 195; Fig. Al - pg. 204); 

decomposing the set of functional requirements and design parameters to create hierarchy 
of functional requirements and a hierarchy of design parameters (e.g. FR and DP hierarchies - 
Fig. 1, pg. 195; chp. 6.1 ->6. 3, pg. 194-196), wherein at least one functional requirement of the 
set of functional requirements is a parent functional requirement at a first level in the hierarchy 
of functional requirements and is decomposed into at least two child functional requirements at a 
second level in the hierarchy that is below the first level, and wherein the at least two child 
functional requirements collectively accomplish the parent functional requirement ( see FR1 -> 
FR11, FR12-Fig. 1;, step 1: FRs mapping DPs, ch. 4.2^4.4, pg. 191-193); 

defining a design matrix that maps each design parameter in the hierarchy of design 
parameters to the at least one functional requirement in the hierarchy of functional requirements 
that the respective design parameter satisfies (e.g. ch. 4.2-> 4.4, pg. 191-193; chp. 6.1->6.3, pg. 
194-196); and 

using the design matrix to define software modules ( Fig. 2-4, pg. 196; ch. 6.4 pg. 197) of 
the software system, wherein at least one functional requirement in the hierarchy of functional 
requirements represents a software object of the software system (e.g. Fig. 3, pg. 196; modules 
Ms - ch. 6.6, pg. 198; ch. 7, pg. 199), and wherein at least one design parameter in the hierarchy 
of design parameters represents an input to the software object (e.g. input to MI 231 - right col., 
ch. 6.2, pg. 195; ch. 6.4 pg. 197). 

But Suh_l does not explicitly disclose that the FR-derived modules being designed from 
the matrix object are object-oriented structures. The concept of modularization of software 
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architecture with parent/child relationship (see ch. 6.1 pg. 194 to ch. 6.4, pg. 197; Fig. 1, 3, 4) 
considered by Suh_l along with reassembling of modules from a database ( see ch. 6.7, pg. 199) 
and reusability implemented via library of software modules ( see ch. 8.1, pg. 200) suggest the 
known benefits of object-oriented implementation of large software systems at the time the 
invention was made, some of which being tracking of changes ( or failures) and understanding 
interaction dependency between modules ( see Suh_l, ch. 10, pg. 203). Suh_2, in a similar 
approach to implement axiomatic design to large systems analogous to Suh_l, teaches the same 
decomposition of levels of software modules via matching of DP/FR using a control matrix; and 
based upon the module derivation, teaches identification of classes as well as its interfaces, and 
attributes or methods thereof to represent a DP ( see Fig. 1, pg. 122; middle column, pg. 124). 
Based on the concept of independent reassembling of modules per development instance and 
reusability control from Suh_l, it would be obvious for one skill in the art at the time the 
invention was made to implement Suh^l modules associated with each FRs, so that these 
modules are reuse object-oriented classes or interfaces as taught by the approach by Suh_2, 
because the creation of OO or classes instances as they are retrieved from reuse can support 
relationships ( as in a interface) between object classes and object operations, such that existing 
designs can be reused to support further decomposition, and/or creation of new designs, or to 
help diagnose or handle tracking due to software change ( see Suh_2: middle pg. 121; middle 
para, pg. 124). 

As per claim 97, Suh_l teaches software modules representing equivalent of hardware 
assemblies ( ch. 4.2 pg. 191) to match functional requirements, but does not explicitly disclose 
that at least one element of the design matrix and the at least one design parameter represents an 
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operation performed by the software object; but in view of the classes and method teaching from 
Suh_2 as set forth above, the operation limitation, i.e: a method by a software object in light of 
00 implementation from above, would have been obvious. 

As per claim 98, Suh_l discloses that wherein the act of defining the set of define 
parameters further comprises determining the set of design parameters by mapping the set of 
functional requirements into a physical implementation domain (e.g. Fig. Al, pg. 204). 

As per claims 99-100, Suh_l discloses an act of determining if the design matrix is 
decoupled (eq. 15, pg. 197); and is not decoupled, manipulating the design matrix into lower 
triangular form (e.g. middle matrix line 2, 7; eq. 15, pg. 197). 

As per claim 101, Suh_l ( in view of Suh_2) discloses wherein the at least one 
functional requirement that represents a software object includes at least two functional 
requirements, and wherein a first of the at least two functional requirements represents a first 
software object and a second of the at least two functional requirements represents a second 
software object (e.g. Fig. 1, ch. 6.1-pg. 194-195; ch. 6.6. pg. 198; ch. 4.5 pg. 193). 

As per claim 102, Suh_l discloses defining a relationship between the first software 
object and the second software object using a junction (e.g. Fig. 2-3, pg. 196). 

As per claim 103, Suh_l discloses defining a third software object by combining the first 
software object and the second software object according to a type of the junction (e.g. Fig. 2-4, 
pg. 196). 

As per claim 104, Suh_l discloses wherein the type of the junction is one of: a 
summation junction; a control junction 1 , or a feedback junction (e.g. Fig. 2-4, pg. 196). 
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As per claim 105, Suh_l discloses computer readable medium encoded with instructions 
that, when executed on a computer system, perform a method of allowing a user to define a 
software system (e.g. software systems - Introduction, pg. 189), the method comprising allowing 
the user to: 

define (a set of functional requirements . . .); 
define (a set of design parameters); 

decompose (the set of functional requirements and design parameters . . .); 
define (a design matrix that maps . . . ); and 

using the design matrix (to define software modules. . .) as recited in claim 96. 
Thus, all of which limitations are respectively addressed according to the rejection set 
forth in claim 96. 

But Suh_l does not disclose that the software modules are to define an object-oriented 
structure. However, this limitation has been addressed as obvious in claim 96. 

As per claims 106-113, these claims correspond to the claims 97-104 for reciting the 
same subject matter therein respectively; hence are rejected using the rationale set forth therein, 
correspondingly. 

Claim Rejections - 35 USC §102 
7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in this 
or a foreign country, before the invention thereof by the applicant for a patent 
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8. Claims 96-1 15 are rejected under 35 U.S.C. 102(a) as being anticipated by Nam P Suh, 
Axiomatic Design of Software, copyright @ August 22, 1999, chapter 5; pp. 2-74 ( hereinafter 
SuhNam - submitted with IDS filed 7/1 7/2006). 

As per claim 96, SuhNam discloses a method of designing a software system, 
comprising: 

defining a set of functional requirements that describe what the software system is to 
achieve (e.g. ch. 5.2.1, pg. 8-12); 

defining a set of design parameters, where each design parameter in the set satisfies at 
least one of the functional requirements (e.g. ch. 5.2.1, pg. 8-12, subpara (i) -> (iv) ); 

decomposing the set of functional requirements and design parameters to create hierarchy 
of functional requirements and a hierarchy of design parameters (e.g. 5.2.1, pg. 8-12, subpara (i) 
-> (iv); ch. 5.3. pg. 14-24 ), wherein at least one functional requirement of the set of functional 
requirements is a parent functional requirement at a first level in the hierarchy of functional 
requirements and is decomposed into at least two child functional requirements at a second level 
in the hierarchy that is below the first level, and wherein the at least two child functional 
requirements collectively accomplish the parent functional requirement (e.g. ch. 5.3, pg. Pg. 14- 
24; Fig. Ex 5.1. a; step 4, pg. 16); 

defining a design matrix that maps each design parameter in the hierarchy of design 
parameters to the at least one functional requirement in the hierarchy of functional requirements 
that the respective design parameter satisfies (e.g. ch. 5.3, pg. Pg. 14-24 ); and 

using the design matrix to define an object-oriented structure (e.g. ch. 5.4 - pg. 36-55 ) of 
the software system, wherein at least one functional requirement in the hierarchy of functional 
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requirements represents a software object of the software system (e.g. ch. 5.4 - pg. 36-55), and 
wherein at least one design parameter in the hierarchy of design parameters represents an input 
to the software object (e.g. step 4, pg. 16; ch. 5.4.3 pg. 41-51). 

As per claims 97-104, see ch. 5.2.1 pg. 8-12: subpara (i) -> (iv); ch. 5.3. pg. 14-24; ch. 
5.4 - pg. 36-55; ch. 5.6, pg. 58-65. 

As per claim 105, SuhNam discloses computer readable medium encoded with 
instructions that, when executed on a computer system, perform a method of allowing a user to 
define a software system, the method comprising allowing the user to: 

define (a set of functional requirements . . .); 

define (a set of design parameters); 

decompose (the set of functional requirements and design parameters . . .); 
define (a design matrix that maps . . . ); and 

using the design matrix (to define software modules...); all of which steps as recited in 
claim 96. 

Thus, all of which limitations are respectively addressed according to the rejection set 
forth in claim 96. 

As per claims 106-113, these claims correspond to the claims 97-104 for reciting the 
same subject matter therein respectively; hence are rejected using the rationale set forth therein, 
correspondingly. 

Response to Arguments 
9. Applicant's arguments submitted 12/20/2006 with respect to claims 96-1 13, have been 
considered but are not persuasive. Following are the Examiner's observations in regard thereto. 
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35 USC § 101 Rejection: 
(A) Applicant has mentioned that the USPTO Interim Guidelines states that 'rather on 
whether the final result achieved by the claimed invention is useful, tangible and concrete' 
(Appl. Rmrks, pg. 2, bottom). The rejection has set forth an analysis by which it is deemed that 
the final result is not tangible; from there, that it is not useful; and thereby not even application 
concrete result. The claim recites defining requirements and parameters, decomposing them to 
create a hierarchical set and defining a matrix to map that hierarchy, and using this matrix to 
define an object-oriented structure. These defining steps of structures and/or hierarchy, matrix 
amounts to software implemented steps action operating of software-implemented entities, like 
parameters, matrix, and OO structure. A programmatic sequence of action to generate defined 
00 structure, matrix ( 2-dimensional structure) or hierarchy of parameters cannot be perceived 
as application real-world data, lacking teaching to that application-level perception effect (e.g. a 
visual tool to display such defined structures); hence data structure remain software entities in 
the layer of runtime execution of the programmatic processe exactly as a Matlab simulation tool 
in a running mode operating on defined structures, containers and 2-D arrays to effectuate a 
programmatic workflow of some industrial algorithm, all of which amounting to internal 
computer flow having programmatically processed entities not visible to an application layer of a 
real-world user. Thus, as recited, the matrix or the 00 being defined and used to define one 
another does not yield a real-world tangible data perceivable at the application level. Non- 
tangible entities remain abstract, and abstract entities cannot be of any application utilization in 
the context of a practical application. Not tangibly accessible leads to being not useful, and 
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consequently not concrete a result in terms of consistent yield for practical, repeatable and useful 
usage. 

(B) Applicants have submitted that a Design Matrix is Useful, has specific, substantial utility 
and is a TANGIBLE RESULT and CONCRETE RESULT (Appl. Rmrks pg. 3-5). The Design 
Matrix as recited has been interpreted as a 2-Dimensional programmatic structure; and based on 
the parameters hierarchy to enable mapping of said matrix to yield more defined 00 structures, 
the rejection has set forth that the Matrix is mere software structure being defined to enable 
defining of more structures in a programmatic process. There are arguably results in terms of 
internally generated concrete and useful entities at the level of the programmatic steps taken by 
the software design method on the onset; but the Interim Guidelines addresses the tangible aspect 
of an Practical Application result, such that the result should be an tangible result satisfying the 
requirements that it be also concrete and useful. Internal entities of a computer method cannot 
be perceived as application tangible data, lacking sufficient and reasonable description to that 
effect. The claim lacks any indication about how the defined structures can be tangibly 
manipulated or accessed at the level of user's application for those structures to be on any useful 
utility at that level. The user might use a GUI tool to execute a MATLAB simulator, and if the 
simulator in its flow of execution maps data and generate more defined structures, the mere fact 
of defining more structures as a result of the computer execution does not necessarily dictate in a 
broad sense the actual realization of any tangible data being accessible at the level of the GUI 
tool. The rejection does not mention the requirement of a hardware support, but only focuses on 
the realization of final result being TANGIBLE, i.e. a final result perceived by the application 
level or by a user making use of the claimed method. Based on the interpretation of what a 
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DESIGN MATRIX amounts to, the final result from the claim is deemed low level respective to 
a application level, and otherwise commensurate only with computer execution internal level, 
thus largely non-perceivable by any user at a GUI level. The above Applicants' points are not 
persuasive. 

USC § 103(a) Rejection: 
(C ) Applicants have submitted that 'Suh T (Appl. Rmrks , pg. 5-6) does not constitute prior 
art by others by virtue of the submission of claims 96-1 13 with removal of claims 1-95, i.e. via 
the request under 1 .48(b). The claims 96-1 1 3 had and have been submitted way back and the 
inventorship corresponding to these claims have been unchanged during the course of 
prosecution since 1 1/23/05 until recently. A proper request under § 1.48(b) has to be timely 
submitted with a change in the claimed subject matter ( e.g. responsive to a Restriction/Election 
action) resulted from an stage or instance thereof in the prosecution. The prosecution has gone 
through stages addressing the above-amended set of claims (96-1 13) with the original Inventive 
Entity for nearly more than two cycles of Office Actions. The currently submission under § 
1 .48(b) suddenly requires change in inventorship whereas the same inventorship underlies the 
subject matter of the above claims 96-1 13 in the past. Lacking explanation as to why an 
unchanged set of claims now necessitates a partial removal of inventorship with respect to 
established requirements stated in 35 CFR § 1.48(b), it is deemed that the request to remove 
inventor's name without any change in the subject matter is not proper. The reference called 
fc Suh_2' remains prior by others with respect to the original Inventive Entity filed 12/06/2000. 
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The arguments about propriety of the references applied in the 35 USC 103 or 102 rejection(s) 
are therefore not overcoming the rejection. Refer to the Objections to the § 1.48(b) as set forth 
above. 

The claims will stand rejected as set forth in the Office Action. 

Conclusion 

10. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Meng-Ai An can be reached on (571)272-3756. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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Tuan A Vu 
Patent Examiner, 
Art Unit 2193 
March 7, 2007 



